The present invention relates to packet-based communications and more particularly to correlation of access codes in packet-based communication systems.
In recent decades, progress in radio and VLSI technology has fostered widespread use of radio communications in consumer applications. Portable devices, such as mobile radios, can now be produced having acceptable cost, size and power consumption.
Although wireless technology is today focused mainly on voice communications (e.g., with respect to handheld radios), this field will likely expand in the near future to provide greater information flow to and from other types of nomadic devices and fixed devices. More specifically, it is likely that further advances in technology will provide very inexpensive radio equipment, which can be easily integrated into many devices. This will reduce the number of cables currently used to interconnect devices. For instance, radio communication can eliminate or reduce the number of cables used to connect master devices with their respective peripherals. The aforementioned radio communications will require an unlicensed band with sufficient capacity to allow for high data rate transmissions. A suitable band is the ISM (Industrial, Scientific and Medical) band at 2.45 GHz, which is globally available. The band provides 83.5 MHz of radio spectrum.
To allow different radio networks to share the same radio medium without coordination, signal spreading is usually applied. In fact, the FCC in the United States currently requires radio equipment operating in the 2.4 GHz band to apply some form of spreading when the transmit power exceeds about 0 dBm. Spreading can either be at the symbol level by applying direct-sequence (DS) spread spectrum techniques, or at the channel level by applying frequency hopping (FH) spread spectrum techniques. The latter is attractive for the radio applications mentioned above since it more readily allows the use of cost-effective radios. A system called Bluetooth™ has been developed to provide pervasive connectivity, especially between portable devices like mobile phones, laptops, PDAs, and other nomadic devices. This system applies frequency hopping to enable the construction of low-power, low-cost radios with a small footprint. The system supports both data and voice. The latter is optimized by applying fast frequency hopping (with a nominal rate of 800 hops/s through the entire 2.4 GHz ISM) in combination with a robust voice coding. The air interface uses time slots with a nominal length of 625 microseconds, which corresponds to the dwell time of the FH. During a time slot, a single packet can be sent. Devices based on the Bluetooth™ system concept can create so called piconets, which comprise a master device, and one or more slave devices connected via the FH piconet channel. During traffic mode, the FH sequence used for the piconet channel is completely determined by the address or identity of the device acting as the master. The system clock of the master device determines the phase in the hopping sequence. In the Bluetooth™ system, each device has a free-running system clock. Each of the slave devices adds a time offset to its clock such that it becomes aligned with the clock of the master device. By using the master address to select the proper hopping sequence and using the time offset to align to the master clock, the slave devices keep in hop synchrony to the master device; that is, master and slave devices remain in contact by hopping synchronously to the same hop frequency or hop carrier. For more details, the reader is referred to, “The Bluetooth radio system,” by J. C. Haartsen, published in IEEE Personal Communications Magazine, Vol. 7, No. 1, February 2000, pp. 28-36.
The hop sequences used in the Bluetooth™ system are generated through a hop selection mechanism as is described in U.S. Pat. No. 6,108,366, issued to J. C. Haartsen on Aug. 22, 2000, and entitled “Method and apparatus for the generation of frequency hopping sequences.” With this method, hop carriers are generated “on the fly”. The mechanism has no inherent memory: address and clock information instantaneously determine the sequence and phase and therefore directly the desired hop carrier. The advantages of such a selection scheme are numerous. By changing address and clock, a device can jump from one FH piconet channel controlled by one address/clock combination to another piconet controlled by another address/clock combination. More information about this aspect of the Bluetooth™ system may be found in U.S. Pat. No. 6,590,928, issued to J. C. Haartsen on Jul. 8, 2003 and entitled “FH piconets in an uncoordinated wireless multi-user system.” In addition, this selection mechanism provides a large number of possible FH sequences. The sequence selection is based on 28 bits in the master identity. As a result, 228 or 268, 435, 456 different hop sequences are defined. The length of each sequence is determined by the master clock which counts from 0 to 227−1 at a rate of 1600 increments per second and wraps around after about 23.3 hours. The number of possible sequences and the size of each sequence make it impossible to store the Bluetooth™ FH sequences and process them off-line. Instead, a selection mechanism is used as described in U.S. Pat. No. 6,108,366 (referenced above).
For a proper operation of the Bluetooth™ hopping channel, the master and the slave have to remain in FH synchrony. The frequency hopping is driven by the native clock of the master of the piconet. At each packet reception, the slave adjusts its clock offset such that the input of the hop selection mechanism is aligned with the input in the master. The slaves use a special synchronization word, called the access code, which precedes the Bluetooth™ packets for timing resynchronization. The access code defined in Bluetooth™ consists of a 4-bit preamble of alternating logical ones and zeroes, followed by a 64-bit sync word. In case a packet header is to follow, the access code is trailed by a 4-bit postamble, also consisting of alternating logical ones and zeroes. The sync word is based on a (64, 30) expurgated block code with a bit-wise Exclusive OR'ed (“EXORed”) overlay of a 64-bit full-length PN sequence. The minimum Hamming distance between different code words is 14. The access code is derived from the 24 least significant bits (LSBs) of the Bluetooth™-Device address (BD_ADDR). Each Bluetooth™ unit has a unique 48-bit BD_ADDR for an unambiguous addressing scheme. In a piconet, each radio packet exchanged between the master and the slaves is preceded by this access code derived from the BD_ADDR of the master. Only packets with the proper access code are accepted by the recipient. The access code is further used for bit and frame synchronization and to adjust the slave clock offset (with respect to the master clock) in order to remain FH synchronized to the master. In the receiver, the received symbol sequence representing the access code is compared with the desired access code (i.e., the reference code). When sufficient symbols (e.g., bits) match, successful reception of the access code is indicated and the synchronization parameters are updated. (As used herein, words such as “indicate” and “declare” are intended to denote any logical mechanism that is asserted when the requirements for deeming that the access code has been successfully received have been satisfied. Such mechanisms include, but are not limited to any one or a combination of the following: generating a particular signal, setting a particular flag, and taking a particular branch in program logic.)
Due to disturbances on the propagation channel, it is expected that some symbols in the received access code might be in error. To accommodate such an operating environment, the system is designed to declare successful reception of an access code even if a number of symbols are erroneous. A threshold k is defined, indicating how many symbols may be in error without preventing a successful access code reception from being indicated. If N is the total number of symbols, then k≦N. If the number of matching symbols is less than k, the access code is rejected. If the desired access code was present, but was rejected because of too many errors, this is called a False Rejection. The false rejection (FR) rate depends not only on the symbol error rate but also on the threshold k: the higher k, the less errors are tolerated and the higher the FR rate. By lowering k, the FR rate is reduced. However, k cannot be chosen too low, as in that case random bit sequences (noise) or other access codes may trigger the receiver; that is, the receiver may think that the correct access code has arrived, when in fact only noise or an incorrect access code have been received. This situation is called a False Alarm. The false alarm rate increases as k is lowered. Clearly there is an optimal threshold k which couples a low FR rate to an acceptable FA rate.
Up to this point, the description has focused on the use of the access code in connection with maintaining synchrony between the master and the slave after a connection has been established (referred to herein as “traffic mode”). However, in Bluetooth™ systems, the access code is also used during the connection establishment or acquisition mode. This mode, more generally referred to herein as “scan mode,” is described in U.S. Pat. No. 6,345,066, issued to J. C. Haartsen on Feb. 5, 2002 and entitled “Reduction of access time delay in FH radio systems using a DS mode.” The access code is considered as a direct-sequence spread spectrum code and used for signaling during initial setup when the FH channel needs to be established. Details on the initial FH synchronization procedures can be found in U.S. Pat. No. 5,940,431, issued to J. C. Haartsen on Aug. 17, 1999 and entitled “Access technique of channel hopping communications system.” In idle state, a Bluetooth™ unit wakes up regularly in a scan mode to listen on a particular frequency carrier either to the access code corresponding to its own BD_ADDR (page scan mode) or to an access code associated with an inquiry mechanism (inquiry scan mode). (That is, the access code in this instance is derived from the receiving unit.) There are 32 different frequencies the idle unit can listen to, but per wake-up instant it listens only to a single frequency. In the next wake-up instant it listens to the next frequency, and so on. The unit that wants to make contact, the paging unit, does not know when the idle unit will wake up and on which frequency. It therefore repeatedly sends the access code sequentially on different frequencies. When the paging unit hops at a 3200 hops/s rate, it takes 10 ms to hop through all the 32 frequencies. If the idle unit listens for at least 10 ms on one of these frequencies, it will certainly receive the access code because one of the paging unit's transmissions will coincide with the frequency the idle unit is listening on. The actual connection setup scheme is a little more complicated (e.g. the 32 frequencies are split into two trains of 16 carriers each by the paging unit) and the interested reader is further referred to the article “The Bluetooth radio system,” by J. C. Haartsen mentioned above, or to the Bluetooth™ specifications.
When the idle unit receives the access code, it confirms the reception by returning a signal to the paging unit, which signal again consists of this access code. Accordingly, in between transmissions, the paging unit also listens for the access code. Once the two access codes are exchanged as a handshaking, the two units are in FH synchronization. In the next packet sent by the paging unit, more synchronization information is included in order to move to a hopping sequence that uses all 79 carriers available in the 2.4 GHz band. It can be seen that in the connection setup, the access code plays a dominant role. In this case too, the received signal is compared with a reference code and only if there is sufficient agreement between the received signal and the reference will the receiver indicate the successful reception of the access code. Again, a threshold k is defined indicating the minimum number of symbols that must match before a successful reception is indicated. As in the ongoing-connection mode (referred to more generally herein as “traffic mode”), the threshold will determine the False Alarm and False Rejection rates.
However, the requirements on FA and FR during the scan mode are completely different from the FA and FR during the traffic mode. In traffic mode, the FR is crucial as it directly has an impact on the overall packet error rate. Therefore, a low threshold k is desirable. In the scan mode, FA is crucial as it affects the power consumption in the idle state. To avoid starting the system on a wrong access code, or even on noise, a high threshold k is desirable. Clearly, there are contradictory requirements in the receiver regarding the match of the received signal with respect to the reference code.
While the problems set forth above have been presented in the context of a Bluetooth™ system, they are by no means restricted to such an environment. To the contrary, such problems would arise in any telecommunications system that relies on a level of correlation between a received access code and an expected access code to make decisions not only with respect to scan mode but also with respect to traffic mode.
It is therefore desirable to have a way of providing good FA and FR characteristics in the traffic mode to obtain acceptable packet error rate, while simultaneously providing good FA and FR characteristics in the scan mode to obtain acceptable power consumption.